Access denied when setting permission for ANONYMOUS LOGON

Applies to: Content Studio ver. 3.2 +

When a user tries to set the browse permissions for the ANONYMOUS LOGON group in Content Studio the action fails with an Access denied error. However there are no problems with other accounts.

Probably there is an invalid value in the Content Studio system setting Anonymous_Account. This value should be the name of the local account used by IIS when it impersonates an anonymous user. When Content Studio sets the browse permission for the ANONYMOUS LOGON group it inserts the READ/EXECUTE permission in the underlying file system, not to the ANONYMOUS LOGON group, but to the IIS anonymous account. Content Studio normally does not have the right to query the IIS metabase for this account so it first tries to get the account name from the setting. If this setting is empty or points to an invalid account Content Studio asks the IIS metabase and recieves Access denied from IIS.

Update the setting named system.Anonymous_Account to reflect the actual account used by IIS to authenticate an anonymous user. This account is normally named IUSR_MACHINENAME where MACHINENAME is the name of the server. If an administrator changes this account you must update this setting as well and remove and restore the permissions for ANONYMOUS LOGON group in Content Studio.
NOTE: From Content Studio version 4.0 build 1009 this information can be set to be read from the registry. If the registry key is set this value will override the setting mentioned above. For more information on this see the link below under the More information section.

This is by design in Content Studio and is an effect of that Content Studio syncronizes its internal permissions with the underlying file system.

For more detailed information see the article How Content Studio determines the IIS anonymous account.